Set default CONFIG_BROADCAST_TABLE_SIZE - #728

If getConfigurationValue returns a non-OK status, the minimum check short-circuits and the code proceeds to write 15. On firmware where the read is unsupported but the write is not, that would shrink the table. This shape is not specific to this PR — every existing minimum=True entry shares it — but it is worth a guard if broadcast table size becomes one of them.

Since a ZBT-2 running bellows is only ever a coordinator, the operative day-to-day pressure is not how much it relays for others but how much it can originate. That is governed by CONFIG_NEW_BROADCAST_ENTRY_THRESHOLD, and the important detail is that the threshold is derived from the table size rather than independent of it. In routing/util/broadcast.h:

#define BROADCAST_TABLE_SIZE sli_zigbee_broadcast_table_size
...
#define NEW_ENTRY_THRESHOLD (BROADCAST_TABLE_SIZE - 6)

BROADCAST_TABLE_SIZE there is the runtime variable, so the threshold is defined six below the table size. Origination capacity is therefore roughly the table size minus six: about 58 on a ZBT-2 at 64, and about 9 if it were 15.

That makes the table size the value governing how many broadcasts the host can send before the stack refuses to originate any more — SiLabs' own wording for the threshold is that "the local device will fail to originate a broadcast message after this threshold is reached". It is very likely why these coordinators ship 64.

Those two figures are the difference described above, quantified: roughly 58 commands before a refusal at 64, against roughly 9 at 15. On current Simplicity SDK firmware the refusal arrives as a generic sl_Status.BUSY, which is the status the legacy mapping noted above should resolve to.

A "limit broadcast messages" option, if one were ever wanted, would sit naturally on this threshold rather than on the table size. CONFIG_NEW_BROADCAST_ENTRY_THRESHOLD is separately settable over EZSP, and lowering it caps what the coordinator originates while leaving the rest of the table available for relaying other devices' broadcasts — much closer to "reserve airtime for unicasts" than shrinking the table, which would cut relay capacity too.

The stack's broadcast logic reads the table size from a runtime variable rather than the compile-time constant — routing/util/broadcast.h defines BROADCAST_TABLE_SIZE as sli_zigbee_broadcast_table_size, which sl_zigbee_configuration.c only initialises from the constant. The NCP side resolves EZSP config ids through a pair of tables: configCodes, the supported ids in order, and configLocations, pointers to the variables they write. Position 6 of the first is 0x2b and entry 6 of the second is sli_zigbee_broadcast_table_size — so CONFIG_BROADCAST_TABLE_SIZE writes exactly the variable the stack reads. Those tables live in the prebuilt libncp-pro-library.a rather than in shipped source, but their relocations name the variables plainly. SiLabs' own host-side framework also sets the same config id, with a documented range of 15–254.

The same pairing puts 0x35 against sli_zigbee_new_broadcast_entry_threshold, which is what makes CONFIG_NEW_BROADCAST_ENTRY_THRESHOLD an independently settable knob rather than only a derived one.

Raising is the direction that cannot work, and the firmware is explicit about it: for these entries the handler compares the requested value against the current one and returns an error rather than storing, so a request above the compiled size fails instead of being clamped. That fits the memory layout — the table is a statically allocated array sized by the compile-time constant, with nothing behind a larger runtime value. One consequence worth knowing if this gets documented: within a single NCP session the value can only ever go down, so recovering a lowered value takes an adapter reset, after which the firmware default applies again.

SiLabs' own comment next to the default says otherwise:

/* The minimum broadcast table size per the Zigbee Pro spec is 9. */
#define SL_ZIGBEE_DEFAULT_BROADCAST_TABLE_SIZE 15

The configurable range is 15–254. R23.2 itself does not specify a broadcast table size; nwkNetworkBroadcastDeliveryTime is listed with a default of "Defined in stack profile", and the familiar 9 s figure comes from the Zigbee PRO stack profile document rather than the base spec.

The same header goes further, and is worth reading alongside the stack comparison in zigpy/ziggurat#43. SiLabs describe 15 not as a spec value but as their own compensation for departing from one:

The ZigBee Pro profile document 074855r05 states a value of 9 seconds for the entry timeout, which is too short. We double the timeout and the table size in order to get the same bandwidth as the spec.

So 15 is the number that exists because their entry timeout departs from the spec — a compensation for holding entries 15–20 s instead of 9 s, sized to land at the same bandwidth. Reading it as a floor the spec imposes gets it backwards.

The burst clamp layered on top has no spec counterpart at all: the same header describes it as approximating "the behavior of the pre-z3.1 stack", which is backwards compatibility rather than conformance. R23.2 section 3.6.6 asks only that a device track each broadcast, drop new ones when the table is full, and expire entries after the delivery time — it sets no table size, no rate, and no burst limit. That is the point the comparison in zigpy/ziggurat#43 makes across stacks, and it puts SiLabs at 15 at the conservative end of the group rather than at the reference point.

This is the strongest form of the argument, and SiLabs' own warning does point at it:

Additionally, this value must be universal for all devices in the network. Otherwise, a single router can overwhelm all its neighbors with more broadcasts than they can support.

Read literally, a coordinator at 64 among neighbours at 15–50 is exactly that asymmetry. Mechanically it would also work, unlike raising: the firmware accepts a lower value and rejects a higher one, and the table is allocated at the compiled size so a smaller runtime size just leaves entries unused.

It would still be the first entry of its kind in bellows. All eight existing minimum=True entries in bellows/ezsp/config.py are capacities — multicast, address, key and source route tables, trust center cache, end device children, supported networks. Everything written unconditionally is a behavioural or protocol setting. The one capacity written unconditionally is CONFIG_PACKET_BUFFER_COUNT, set to 0xFF, so it cannot lower anything either. Nothing in the file currently shrinks a table below what the firmware chose.

There is also a second-order effect that runs against the intuition that a smaller table is the polite choice. Passive acknowledgement means a router keeps retransmitting a broadcast, up to nwkMaxBroadcastRetries times, at any neighbour it has not heard relay it (R23.2 section 3.6.6). A coordinator that drops a broadcast because its table is full does not go quietly — its neighbours retransmit at it. Clamping therefore buys less airtime than it appears to, and may cost some.

Worth conceding, since it is the strongest technical form of the concern here.

The threshold governs what the coordinator originates. A coordinator with a 64-entry table can still relay a lot of other devices' broadcast traffic, and if it sits between two parts of a mesh it can forward more distinct concurrent transactions into one side than 15-entry routers there can track. Lowering the origination limit would not change that.

There is a caveat on that caveat: routing/util/broadcast.h describes the same threshold as gating any new entry added within the last 10–15 s rather than originated ones specifically, in which case lowering it would throttle relaying too. The two SDK descriptions disagree and the implementation is in the closed libraries, so I cannot say which governs.

Either way the effect looks bounded. A router whose table is full drops the frame and neither relays it nor passes it up (R23.2 section 3.6.6), so it cannot be pushed past its own capacity — what changes is which broadcasts occupy its slots, plus the airtime of the extra relays. Where that does bite is the original worry about floods breaking network operations: link status is a one-hop broadcast that is never relayed and so is unaffected, but Device_annce (0xFFFD) and Mgmt_Permit_Joining_req (0xFFFC) are ordinary tracked broadcasts, so saturated peer tables really can make a newly joined device invisible or permit-join unreliable. It also requires the coordinator to be the only path between two regions; in a reasonably meshed network those transactions arrive from other routers anyway. And on a typical ZHA network most broadcasts originate at the coordinator in the first place, so there is not much third-party traffic to amplify.

That reads as a reason to leave the shipped configuration alone rather than to pick a different number for it.

This is not this PR's stated rationale, but it has come up in zigpy/ziggurat#43 and zigpy/ziggurat#55, and it matters here in one narrow way: if there were a broadcast limiter below the Zigbee layer, a larger broadcast table would not actually deliver the extra headroom described above. As far as I can tell there is not, so it does.

802.15.4 does have broadcasts — destination short address 0xFFFF, unacknowledged, and beacon requests are pure MAC broadcasts with no Zigbee layer involved at all. What it does not define is any relaying of one. R23.2 section 3.6.6 places the relay decision, the duplicate check and the drop-when-full rule in the network layer's Broadcast Transaction Table; the MAC's part is issuing MCPS-DATA.request to 0xFFFF with acknowledgement disabled, repeated up to nwkMaxBroadcastRetries times by the NWK layer. Radius and destination-type checks gate relaying alongside the BTT. So all of the limiting lives in the stack, and on EmberZNet it is visibly in routing/util/broadcast.h — the table, the aging buckets and the burst clamp discussed above.

Two caveats on how strongly to put that. 802.15.4 standardises no broadcast rate limiting, which is not the same as proving that no MAC implementation anywhere could throttle broadcast frames — there is simply no sign of one here. And there are real MAC-level effects under load that can look like a broadcast limiter without being one: CSMA/CCA channel access failures, the absence of MAC acknowledgement and retries on broadcast frames, and finite firmware queues. Those hit all traffic rather than broadcasts specifically, and the radio counters distinguish them — COUNTER_BROADCAST_TABLE_FULL rising points at the table, COUNTER_PHY_CCA_FAIL_COUNT at airtime.

A useful cross-check, if the closed EmberZNet libraries are not satisfying: OpenThread is an unrelated stack over the same radio standard and is fully open source. Its multicast forwarding control is also at the network layer, in MPL (src/core/net/ip6_mpl.cpp), with its own duplicate-detection table of 35 entries at 5 s. Two independent stacks over 802.15.4 both had to build this above the MAC.